Skip to content

Conversation

@danieldresser-ie
Copy link
Contributor

We shouldn't merge this before we fully sort out the Gaffer side as well, to make sure that everything works with the new API ( I think I've got everything working in Gaffer now, but it's not cleaned up enough to put the PR up yet ). But the Cortex side should be good to review now.

Known questions currently:

  • have I gotten all the names of things right? I've done a lot of renaming of "spline" -> "ramp", some of which is a bit ambiguous. When converting a ramp to OSL conventions, is the variable holding it still named "ramp", or is it called a "spline" once it's converted? I've gone with basically calling everything a "ramp", but I could have missed something, or gone to far in the search and replace.
  • I should probably bind fromOSL/toOSL to Python and write unit tests for these functions, if we're happy with this API ( the overall behaviour of this is already covered by ShaderNetworkAlgoTest.testRampConversion though )
  • There's an outstanding TODO in src/IECoreGL/ShaderStateComponent.cpp, which currently converts SplineData to textures. Now that we're using Ramps for shader parameters, it seems possible that this should be updated to look for RampData instead? I'm not sure where this is being used though ... if it's being used in Gaffer ( maybe for light visualisers, though I didn't find any examples of this? ) then it needs to be updated, but if it's only being used elsewhere, then maybe anyone who is still using it would benefit more from keeping the old behaviour?

@danieldresser-ie
Copy link
Contributor Author

Huh, the build failure on Mac OS is pretty weird ... it's in a file I shouldn't have affected at all, and don't immediately see any way I've touched ... it's in CurvesPrimitiveEvaluator ( the other sort of spline ), and it appears to be a naming clash with something named "linear", but the only thing I'm aware of having added named linear is IECore::RampInterpolation::Linear ( with a capital, in a namespace, and not even included here? ). Odd.

Copy link
Member

@johnhaddon johnhaddon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Daniel! A few comments inline - I think the main topic of discussion is how doable it would be to move some of the Ramp stuff to ShaderNetworkAlgo...perhaps we can talk about that in the meeting that started one minute ago :)

When converting a ramp to OSL conventions, is the variable holding it still named "ramp", or is it called a "spline" once it's converted?

I'd be inclined to call the OSL variables spline*, to indicate the transformation.

There's an outstanding TODO in src/IECoreGL/ShaderStateComponent.cpp, which currently converts SplineData to textures...but if it's only being used elsewhere, then maybe anyone who is still using it would benefit more from keeping the old behaviour?

That would be my guess - I think the most likely client would also be using SplineParameter. Maybe folks at IE will know more, but I don't know of any Gaffer-side uses.

Huh, the build failure on Mac OS is pretty weird .

Yeah, this is nothing to do with the PR - it was broken previously. My bad - I merged a PR from Paul without noticing the failure on Mac, and need to find time to fix it (since we aren't shipping anything on Mac, it's not urgent).

@johnhaddon
Copy link
Member

One more quick note - this PR needs to target main rather than RB-10.6, since it contains breaking changes.

@danieldresser-ie danieldresser-ie changed the base branch from RB-10.6 to main December 3, 2025 01:55
@danieldresser-ie
Copy link
Contributor Author

danieldresser-ie commented Dec 3, 2025

Addressed all feedback ( aside from the oslStartPointMultiplicity / oslStartPointDuplication naming/off-by-one issue that I realized at the last minute probably needs one last tweak ).

Retargeted to main.

Added a couple of Changelog entries ready to be squashed in ( oh, and I should probably add a separate changelog entry to flag the deprecations in de8f2b9 ).

When converting a ramp to OSL conventions, is the variable holding it still named "ramp", or is it called a "spline" once it's converted?
I'd be inclined to call the OSL variables spline*, to indicate the transformation.

I attempted to follow this convention with 15b62d4. I'm not fully convinced I like this, it feels a bit confusing having to reason about exactly what point in the conversion process it starts being named spline, but think it's fairly consistent now.

@johnhaddon
Copy link
Member

Thanks Daniel - updates all look good to me. I think we do still want to update the oslStartPointMultiplicity() semantics, but might as well get everything squashed while doing that.

@danieldresser-ie
Copy link
Contributor Author

Updated oslStartPointMultiplicity() semantics, added Changelog entry for ShaderNetworkAlgo deprecated function removals, and squashed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants